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Elliptic Curve Cryptography Subject Public Key Information 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
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Abstract 


This document specifies the syntax and semantics for the Subject 
Public Key Information field in certificates that support Elliptic 
Curve Cryptography. This document updates Sections 2.3.5 and 5, and 
the ASN.1 module of "Algorithms and Identifiers for the Internet 
X.509 Public Key Infrastructure Certificate and Certificate 
Revocation List (CRL) Profile", RFC 3279. 
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1. Introduction 


This document specifies the format of the subjectPublicKeyInfo field 
in X.509 certificates [PKI] that use Elliptic Curve Cryptography 


(ECC). It updates RFC 3279 [PKI-ALG]. This document specifies the 
encoding formats for public keys used with the following ECC 
algorithms: 


o Elliptic Curve Digital Signature Algorithm (ECDSA); 
o Elliptic Curve Diffie-Hellman (ECDH) family schemes; and 
o Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes. 


Two methods for specifying the algorithms that can be used with the 
subjectPublicKey are defined. One method allows the key to be used 
with any ECC algorithm, while the other method restricts the usage of 
the key to specific algorithms. To promote interoperability, this 
document indicates which is required to implement for Certification 
Authorities (CAs) that implement ECC algorithms and relying parties 
that claim to process ECC algorithms. 


The ASN.1 [X.680] module in this document includes ASN.1 for ECC 
algorithms. It also includes ASN.1 for non-ECC algorithms defined in 
[PKI-ALG] and [PKI-ADALG], even though the associated text is 
unaffected. By updating all of the ASN.1 from [PKI-ALG] in this 
document, implementers only need to use the module found in this 
document. 
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1.1. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [MUSTSHOULD]. 

2. Subject Public Key Information Fields 


In the X.509 certificate, the subjectPublicKeyInfo field has the 
SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 


SubjectPublicKeyInfo ::= SEQUENCE { 
algorithm AlgorithmIdentifier, 


subjectPublicKey BIT STRING 
} 


The fields in SubjectPublicKeyInfo have the following meanings: 


o algorithm is the algorithm identifier and parameters for the ECC 
public key. 


o subjectPublicKey is the ECC public key. See Section 2.2. 


The AlgorithmIdentifier type, which is included for convenience 
[PKI], is defined as follows: 


AlgorithmIdentifier ::= SEQUENCE 4 
algorithm OBJECT IDENTIFIER, 
parameters ANY DEFINED BY algorithm OPTIONAL 


} 
The fields in AlgorithmIdentifier have the following meanings: 


o algorithm identifies the cryptographic algorithm with an object 
identifier. See Section 2.1. 


o parameters, which are optional, are the associated parameters 
for the algorithm identifier in the algorithm field. See 
Section 2.1.1. 


2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers 
The algorithm field in the SubjectPublicKeyInfo structure [PKI] 
indicates the algorithm and any associated parameters for the ECC 


public key (see Section 2.2). Three algorithm identifiers are 
defined in this document: 
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o id-ecPublicKey indicates that the algorithms that can be used 
with the subject public key are unrestricted. The key is only 
restricted by the values indicated in the key usage certificate 
extension (see Section 3). id-ecPublicKey MUST be supported. 
See Section 2.1.1. This value is also included in certificates 
when a public key is used with ECDSA. 


o id-ecDH indicates that the algorithm that can be used with the 
subject public key is restricted to the Elliptic Curve Diffie- 
Hellman algorithm. See Section 2.1.2. id-ecDH MAY be 
supported. 


o id-ecMQV indicates that the algorithm that can be used with the 
subject public key is restricted to the Elliptic Curve Menezes- 
Qu-Vanstone key agreement algorithm. See Section 2.1.2. 
id-ecMQV MAY be supported. 

2.1.1. Unrestricted Algorithm Identifier and Parameters 


The "unrestricted" algorithm identifier is: 


id-ecPublicKey OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) ansi-X9-62(10045) keyType(2) 1 } 


The public key (ECPoint) syntax is described in Section 2.2. 


The parameter for id-ecPublicKey is as follows and MUST always be 


present: 
ECParameters ::= CHOICE { 
namedCurve OBJECT IDENTIFIER 


-- implicitCurve NULL 
-- specifiedCurve SpecifiedECDomain 


-- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 
-- Details for SpecifiedECDomain can be found in [X9.62]. 

-- Any future additions to this CHOICE should be coordinated 
—- with ANSI X9. 


The fields in ECParameters have the following meanings: 
o namedCurve identifies all the required values for a particular 
set of elliptic curve domain parameters to be represented by an 
object identifier. This choice MUST be supported. See Section 


Seck ks 


o implicitCurve allows the elliptic curve domain parameters to be 
inherited. This choice MUST NOT be used. 
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o specifiedCurve, which is of type SpecifiedECDomain type (defined 
in [X9.62]), allows all of the elliptic curve domain parameters 
to be explicitly specified. This choice MUST NOT be used. See 
Section 5, "ASN.1 Considerations". 


The addition of any new choices in ECParameters needs to be 
coordinated with ANSI X9. 


The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place 
within a certificate where the elliptic curve domain parameters may 
be located. If the elliptic curve domain parameters are not present, 
then clients MUST reject the certificate. 


2.1.1.1. Named Curve 


The namedCurve field in ECParameters uses object identifiers to name 


well-known curves. This document publishes curve identifiers for the 
fifteen NIST-recommended curves [FIPS186-3]. Other documents can 
publish other name curve identifiers. The NIST-named curves are: 


-- Note that in [X9.62] the curves are referred to as ’ansix9’ as 
-- opposed to ‘sec’. For example, secp192r1 is the same curve as 
-- ansix9p192r1. 


-- Note that in [PKI-ALG] the secp192r1 curve was referred to as 
-- primel92vl1 and the secp256rl curve was referred to as 
-- prime256v1. 


-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224rl as 
-- P-224, secp256r1 as P-256, secp384rl as P-384, and secp52lrl as 
-- P-521. 


secp192r1 OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) ansi-X9-62 (10045) curves (3) 
prime(1) 1 } 


sect163k1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 1 } 


sect163r2 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization (3) certicom(132) curve(0) 15 } 


secp224r1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 33 } 


sect233k1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 26 } 
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sect233r1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 27 } 


secp256r1 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves (3) 
prime (1) 7 } 


sect283k1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 16 } 


sect283r1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 17 } 


secp384rl OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 34 } 


sect409k1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 36 } 


sect409r1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 37 } 


secp521r1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 35 } 


sect571k1 OBJECT IDENTIFIER ::= 4 
iso(1) identified-organization(3) certicom(132) curve(0) 38 } 


sect571rl OBJECT IDENTIFIER ::= 4 
iso(1) identified-organization(3) certicom(132) curve(0) 39 } 


„2. Restricted Algorithm Identifiers and Parameters 


Two "restricted" algorithms are defined for key agreement algorithms: 
the Elliptic Curve Diffie-Hellman (ECDH) key agreement family schemes 
and the Elliptic Curve Menezes-Qu-Vanstone (ECMOV) key agreement 
family schemes. Both algorithms are identified by an object 
identifier and have parameters. The object identifier varies based 
on the algorithm, but the parameters are always ECParameters and they 
MUST always be present (see Section 2.1.1). 


The ECDH algorithm uses the following object identifier: 


id-ecDH OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) schemes (1) 
ecdh(12) } 
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The ECMQV algorithm uses the following object identifier: 


id-ecMOV OBJECT IDENTIFIER ::= { 


iso(1) identified-organization(3) certicom(132) schemes (1) 


ecmqv (13) } 
Subject Public Key 


The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. 
ECC public keys have the following syntax: 


ECPoint ::= OCTET STRING 
Implementations of Elliptic Curve Cryptography according to this 
document MUST support the uncompressed form and MAY support the 
compressed form of the ECC public key. The hybrid form of the ECC 
public key from [X9.62] MUST NOT be used. As specified in [SEC1]: 


o The elliptic curve public key (a value of type ECPoint that is 


an OCTET STRING) is mapped to a subjectPublicKey (a value of 
type BIT STRING) as follows: the most significant bit of the 
OCTET STRING value becomes the most significant bit of the BIT 
STRING value, and so on; the least significant bit of the OCTET 
STRING becomes the least significant bit of the BIT STRING. 
Conversion routines are found in Sections 2.3.1 and 2.3.2 of 
[SEC1]. 


The first octet of the OCTET STRING indicates whether the key is 
compressed or uncompressed. The uncompressed form is indicated 
by 0x04 and the compressed form is indicated by either 0x02 or 
0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if 
any other value is included in the first octet. 


Key Usage Bits 


If the keyUsage extension is present in a Certification Authority 


certificate that indicates id-ecPublicKey in 


SubjectPublicKeyInfo, then any combination of the following values 
MAY be present: 


digitalSignature; 
nonRepudiation; 
keyAgreement; 
keyCertSign; and 
cRLSign. 
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If the CA certificate keyUsage extension asserts keyAgreement, then 
it MAY assert either encipherOnly or decipherOnly. However, this 
specification RECOMMENDS that if keyCertSign or cRLSign is present, 
then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be 
present. 


If the keyUsage extension is present in an End Entity (EE) 
certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, 
then any combination of the following values MAY be present: 


digitalSignature; 
nonRepudiation; and 
keyAgreement. 


If the EE certificate keyUsage extension asserts keyAgreement, then 
it MAY assert either encipherOnly or decipherOnly. 


If the keyUsage extension is present in a certificate that indicates 
id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following MUST 
be present: 


keyAgreement; 
one of the following MAY be present: 


encipherOnly; or 
decipherOnly. 


If the keyUsage extension is present in a certificate that indicates 
id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following 
values MUST NOT be present: 


digitalSignature; 
nonRepudiation; 
keyTransport; 
keyCertSign; and 
cRLSign. 


4. Security Considerations 
The security considerations in [PKI-ALG] apply. 
When implementing ECC in X.509 Certificates and Certificate 
Revocation Lists (CRLs), there are three algorithm-related choices 


that need to be made for the signatureAlgorithm field in a 
Certificate or CertificateList: 
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1) What is the public key size? 


2) What is the hash algorithm [FIPS180-3]? 


3) What is the curve? 


March 2009 


Consideration must be given by the CA to the strength of the security 
provided by each of these choices. 
where a strong symmetric cipher with a key of X bits is said to 


provide X bits of security. 
security provided by each choice are roughly equivalent. 
following table provides comparable minimum bits of security 


[SP800-57 
also list 


Minimum 
Bits of 
Security 


Turner, et a 


] for the ECDSA key sizes 
s curves (see Section 2.1 


160-223 


| 
+ 
| 
| 
+ 
| 
| 


— + ———+——— + 


l. 


Message 
Digest 
Algorithms 


| 
+ 
| 
HA-224 | 
| 
+ 
| 
| 


— PP + 


tia ee ad +=- 


Standards 


Security is measured in bits, 


It is recommended that the bits of 


and message digest algorithms. It 


.1.1) for the key sizes. 


Curves 


sect163k1 
secp163r2 
secp192r1 


secp224rl 
sect233k1 
sect233r1 


secp256rl 
sect283k1 
sect283r1 


secp384rl 
sect409k1 
sect409r1 


secp521r1 
sect571k1 
sect571r1 


Track 
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To promote interoperability, the following choices are RECOMMENDED: 


Minimum ECDSA Message Curves 
Bits of Key Size Digest 

Security | | Algorithms | 

iati iai poop po 
80 | 192 | SHA-256 | secp192r1 
ere KEE E 
112 | 224 | SHA-256 | secp224r1 
— poop po 
128 | 256 | SHA-256 | secp256r1 
siii poop po 
192 | 384 | SHA-384 | secp384r1 
— poop 
256 || S22 | SHA-512 | secp521r1 
ESI poop po 


Using a larger hash value and then truncating it consumes more 
processing power than is necessary. This is more important on 
constrained devices. Since the signer does not know the environment 
that the recipient will use to validate the signature, it is better 
to use a hash function that provides the desired hash value output 
size, and no more. 


There are security risks with using keys not associated with well- 
known and widely reviewed curves. For example, the curve may not 
satisfy the Menezes-Okamoto-Vanstone (MOV) condition [X9.62] or the 
curve may be vulnerable to the Anomalous attack [X9.62]. 
Additionally, either a) all of the arithmetic properties of a 
candidate ECC public key must be validated to ensure that it has the 
unique correct representation in the correct (additive) subgroup (and 
therefore is also in the correct EC group) specified by the 
associated ECC domain parameters, or b) some of the arithmetic 
properties of a candidate ECC public key must be validated to ensure 
that it is in the correct group (but not necessarily the correct 
subgroup) specified by the associated ECC domain parameters 
[SP800-56A]. 


As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is 
discouraged. It is still reasonable to use MD2 and MD5 to verify 
existing signatures. 


5. ASN.1 Considerations 
[X9.62] defines additional options for ECParameters and ECDSA-Sig- 
Value [PKI-ALG]. If an implementation needs to use these options, 


then use the [X9.62] ASN.1 module. This RFC contains a conformant 
subset of the ASN.1 module defined in [X9.62]. 
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If an implementation generates a PER [X.691] encoding using the ASN.1 
module found in this specification, it might not achieve the same 
encoded output as one that uses the [X9.62] module. PER is not 
required by either the PKIX or S/MIME environments. If an 
implementation environment requires PER, then implementation concerns 
are less likely with the use of the [X9.62] module. 


IANA Considerations 


This document makes extensive use of object identifiers to register 
public key types, elliptic curves, and algorithms. Most are 
registered in the ANSI X9.62 arc, with the exception of the hash 
algorithms (which are in the NIST arc) and many of the curves (which 
are in the Certicom Inc. arc; these curves have been adopted by ANSI 
and NIST). Additionally, an object identifier is used to identify 
the ASN.1 module found in Appendix A. It is defined in an arc 
delegated by IANA to the PKIX Working Group. No further action by 
IANA is necessary for this document or any anticipated updates. 
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Appendix A. ASN.1 Module 


PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms(5) pkix(7) id-mod(0) 45 } 


DEFINITIONS EXPLICIT TAGS ::= 
BEGIN 
-- EXPORTS ALL; 
IMPORTS 
-—- From RFC 4055 [RSAOAEP ] 
id-sha224, id-sha256, id-sha384, id-sha512 

FROM PKIX1-PSS-OAEP-Algorithms 

{ iso(1) identified-organization(3) dod(6) internet (1) 


security(5) mechanisms(5) pkix(7) id-mod(0) 
id-mod-pkixl-rsa-pkalgs (33) } 


-- Message Digest Algorithms 


—— MD-2 
-- Parameters are NULL 


id-md2 OBJECT IDENTIFIER = { 
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 } 


—-— MD-5 
-- Parameters are NULL 


id-md5 OBJECT IDENTIFIER = { 
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 } 


-- SHA-1 
-- Parameters are preferred absent 


id-shal OBJECT IDENTIFIER ::= 4 
iso(1) identified-organization(3) oiw(14) secsig(3) 
algorithm(2) 26 } 


—— SHA-224 
-- Parameters are preferred absent 
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-- id-sha224 OBJECT IDENTIFIER ::= { 

== joint-iso-itu-t (2) country(16) us(840 
za csor (3) nistalgorithm(4) hashalgs (2) 
—- SHA-256 

-- Parameters are preferred absent 


) organization(1) gov(101) 
4 } 


-- id-sha256 OBJECT IDENTIFIER ::= { 
S joint-iso-itu-t (2) country(16) us(840 
—— csor(3) nistalgorithm(4) hashalgs (2) 


) organization(1) gov(101) 
1) 

-- SHA-384 

-- Parameters are preferred absent 


-- id-sha384 OBJECT IDENTIFIER ::= { 
== joint-iso-itu-t (2) country(16) us(840 
== csor(3) nistalgorithm(4) hashalgs (2) 


) organization(1) gov(101) 
2 } 

-- SHA-512 

-- Parameters are preferred absent 


-- id-sha512 OBJECT IDENTIFIER ::= { 
== joint-iso-itu-t (2) country(16) us(840) organization(1) gov(101) 
== csor (3) nistalgorithm(4) hashalgs (2) 3 } 


-- Public Key (PK) Algorithms 


-- RSA PK Algorithm and Key 


rsaEncryption OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } 


RSAPublicKey ::= SEQUENCE { 
modulus INTEGER, -- n 
publicExponent INTEGER -- e 


} 


-- DSA PK Algorithm, Key, and Parameters 


id-dsa OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) x9-57(10040) x9algorithm(4) 1 } 


DSAPublicKey ::= INTEGER -- public key, y 
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DSS-Parms ::= SEQUENCE { 
p INTEGER, 
q INTEGER, 
g INTEGER 

} 


-- Diffie-Hellman PK Algorithm, Key, and Parameters 


dhpublicnumber OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) ansi-x942(10046) number-type(2) 1 } 


DHPublicKey ::= INTEGER -- public key, y = g*x mod p 
DomainParameters ::= SEQUENCE { 

p INTEGER, -- odd prime, p=jq +1 

g INTEGER, -- generator, g 

q INTEGER, == factor of p.1 

j INTEGER OPTIONAL, -- subgroup factor, j>= 2 


validationParms ValidationParms OPTIONAL 
} 


ValidationParms ::= SEQUENCE { 
seed BIT STRING, 
pgenCounter INTEGER 

} 


-- KEA PK Algorithm and Parameters 
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 


joint-iso-itu-t (2) country(16) us(840) organization(1) gov(101) 
dod(2) infosec(1) algorithms(1) 22 } 


KEA-Parms-Id ::= OCTET STRING 


-- Sec 2.1.1 Unrestricted Algorithm ID, Key, and Parameters 
-- (ECDSA keys use id-ecPublicKey) 


id-ecPublicKey OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType (2) 1 } 


ECPoint ::= OCTET STRING 
-- Parameters for both Restricted and Unrestricted 
ECParameters ::= CHOICE { 


namedCurve OBJECT IDENTIFIER 
-- implicitCurve NULL 


Turner, et al. Standards Track [Page 15] 


REC 5480 ECC SubjectPublicKeyInfo Format March 2009 


-- specifiedCurve SpecifiedECDomain 


-- implicitCurve and specifiedCurve MUST NOT be used in PKIX. 
-- Details for SpecifiedECDomain can be found in [X9.62]. 

-- Any future additions to this CHOICE should be coordinated 
—— with ANSI X9. 


-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECDH 


id-ecDH OBJECT IDENTIFIER ::= 4 
iso(1) identified-organization(3) certicom(132) schemes (1) 
ecdh (12) } 

-- ECPoint ::= OCTET STRING 


-- Parameters are ECParameters. 
-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECMOV 
id-ecMOV OBJECT IDENTIFIER ::= { 


iso(1) identified-organization(3) certicom(132) schemes (1) 
ecmqv (13) } 


-- ECPoint ::= OCTET STRING 


-- Parameters are ECParameters. 


-- Signature Algorithms 


-—- RSA with MD-2 
-- Parameters are NULL 


md2WithRSAEncryption OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 } 


-- RSA with MD-5 
-- Parameters are NULL 


md5WithRSAEncryption OBJECT IDENTIFIER ::= 4 
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } 


-- RSA with SHA-1 
-- Parameters are NULL 


shalWithRSAEncryption OBJECT IDENTIFIER ::= 4 
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 
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-- DSA with SHA-1 
-- Parameters are ABSENT 


id-dsa-with-shal OBJECT IDENTIFIER ::= { 
iso(1) member-body (2) us(840) x9-57(10040) x9algorithm(4) 3 } 


-- DSA with SHA-224 
-- Parameters are ABSENT 


id-dsa-with-sha224 OBJECT IDENTIFIER ::= { 
joint-iso-ccitt (2) country(16) us(840) organization(1) gov(101) 
csor(3) algorithms(4) id-dsa-with-sha2(3) 1 } 


-- DSA with SHA-256 
-- Parameters are ABSENT 


id-dsa-with-sha256 OBJECT IDENTIFIER ::= { 
joint-iso-ccitt (2) country(16) us(840) organization(1) gov(101) 
csor(3) algorithms(4) id-dsa-with-sha2(3) 2 } 


-- ECDSA with SHA-1 
-- Parameters are ABSENT 


ecdsa-with-SHAl OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 } 


-- ECDSA with SHA-224 
-- Parameters are ABSENT 


ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures (4) 
ecdsa-with-SHA2 (3) 1 } 


-- ECDSA with SHA-256 
-- Parameters are ABSENT 


ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures (4) 
ecdsa-with-SHA2 (3) 2 } 


—— ECDSA with SHA-384 
-- Parameters are ABSENT 


ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures (4) 
ecdsa-with-SHA2(3) 3 } 
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—-— ECDSA with SHA-512 
-- Parameters are ABSENT 


ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures (4) 
ecdsa-with-SHA2(3) 4 } 


-- Signature Values 


-- DSA 


DSA-Sig-Value ::= SEQUENCE { 
r INTEGER, 
s INTEGER 

} 


-- ECDSA 


ECDSA-Sig-Value ::= SEQUENCE { 
r INTEGER, 
s INTEGER 


-- Named Elliptic Curves 


-- Note that in [X9.62] the curves are referred to as ’ansixX9’ as 
-- opposed to ’sec’. For example secplO2rl is the same curve as 
-- ansix9p192r1. 


-- Note that in [PKI-ALG] the secp192r1 curve was referred to as 
-- primel92v1 and the secp256r1 curve was referred to as prime256v1. 


-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224rl as 
-- P-224, secp256r1 as P-256, secp384r1 as P-384, and secp52lrl as 
= VP 5244, 


secp192r1 OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves (3) 
prime (1) 1 } 


sect163k1 OBJECT IDENTIFIER ::= { 
iso(1) identified-organization(3) certicom(132) curve(0) 1 } 
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sect163r2 OBJECT IDENTIFIER 
iso(1) 


secp224rl OBJECT IDENTIFIER 
iso(1) 


sect233k1 OBJECT IDENTIFIER 
iso(1) 


sect233r1 OBJECT IDENTIFIER 
iso(1) 


secp256r1 OBJECT IDENTIFIER 
iso(1) member-body (2) 
prime (1) 7 } 


sect283k1 OBJECT IDENTIFIER 
iso (1) 


sect283rl OBJECT IDENTIFIER 
iso (1) 


secp384r1 OBJECT IDENTIFIER 
iso(1) 


sect409k1 OBJECT IDENTIFIER 
iso (1) 


sect409r1 OBJECT IDENTIFIER 
iso (1) 


secp521r1 OBJECT IDENTIFIER 
iso(1) 


sect571k1 OBJECT IDENTIFIER 
iso(1) 


sect571r1 OBJECT IDENTIFIER 


iso(1) 
END 
Turner, et al. 
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